Medical Device Quality: Why Software Is More Challenging Than Hardware

The U.S. Food and Drug Administration’s (FDA) Quality System Regulation 21 CFR Part 820.30(g) states, “Design validation shall include software validation and risk analysis, where appropriate.” The words, “where appropriate,” indicate that further guidance is necessary to successfully comply with the regulation. FDA’s guidance document, “General Principles of Software Validation,” is an important first read in that regard, but many medical device manufacturers are not sufficiently familiar with it.

It is impossible to imagine the medical device industry today without the software revolution. From defibrillators to infusion pumps and robotic surgical systems, a broad range of devices relies on software to function safely and effectively. At the same time, medical device software has introduced a level of complexity that dwarfs anything seen before in the field. This column addresses some basic facts about medical device software and how quality professionals, together with executive management, can work together to ensure that FDA’s rigorous requirements are satisfied.

Note that FDA has separate requirements for medical device software and quality system software. This column addresses only the software that is part of a medical device, such as software that triggers an alarm when a product fails. Other software, such as that used by a medical device manufacturer to manage complaints in its quality system, is outside of the scope of this discussion.

In October 2017, FDA released two new final guidance documents on the same day: “Deciding When to Submit a 510(k) for a Change to an Existing Device” and “Deciding When to Submit a 510(k) for a Software Change to an Existing Device.” In other words, medical device software changes have so many unique challenges and risks that they earn a guidance document of their own, separate from all other device changes.


 

 
The Problem: Software Is Different from Hardware
Validation is at the heart of device design, and the validation of software design is especially challenging. Even though FDA’s guidance document, “General Principles of Software Validation,” was last updated in January 2002, that guidance is still highly relevant and useful. When a medical device incorporates software, FDA expects the manufacturer to be well-read in the guidance document.

Furthermore, FDA does not intend the guidance document on software validation to be read only by software developers or quality engineers, as it states, “Software engineering needs an even greater level of managerial scrutiny and control than hardware engineering.” The guidance is written in laymen’s terms, so executive management is not excused from this responsibility, even when they have limited experience in software development.

To get to the heart of the problem, the guidance document on software validation includes the deceptively simple statement: “Software is different from hardware.” Actually, there are many complex differences between software and hardware, and understanding those differences is key to ensuring that software validation will pass FDA muster. The comparison chart (above and on the previous page) is adapted from, and expands on, the FDA guidance.

The Solution: Software Validation Driven by Rigorous Requirements
Both of the last two differences in the chart use the phrase, “a clear set of detailed requirements.” This is the most crucial element for proper software validation, and one that is frequently neglected. The flow chart figure on page 20 illustrates how requirements play an early and crucial role in software development.

During the phases that developers are coding and testing the software, the requirements enter a tunnel that is closed to non-developers, and the software emerges from the other side as a complete design. The resulting software can support a safe and effective device only if executive management and other stakeholders have reviewed a detailed and unambiguous set of requirements. Quality and regulatory teams can expedite this crucial phase by ensuring smooth communications between engineering and the rest of the organization.